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Abstract

   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) block that allows reporting of a post-repair loss count metric
   for a range of RTP applications.  In addition, another metric,
   repaired loss count, is also introduced in this report block for
   calculating the pre-repair loss count when needed, so that the RTP
   sender or a third-party entity is able to evaluate the effectiveness
   of the repair methods used by the system.
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1.  Introduction

   RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain
   some rough statistics about the data received from the particular
   source indicated in that block.  One of them is the cumulative number
   of packets lost, which is called the pre-repair loss metric in this
   document.  This metric conveys information regarding the total number
   of RTP data packets that have been lost since the beginning of the
   RTP session.

   However, this metric is measured on the media stream before any loss-
   repair mechanism, e.g., retransmission [RFC4588] or Forward Error
   Correction (FEC) [RFC5109], is applied.  Using a repair mechanism
   usually results in recovering some or all of the lost packets.  The
   recovery process does not reduce the values reported by the two loss
   metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the
   cumulative loss.  Hence, the sending endpoint cannot infer the
   performance of the repair mechanism based on the aforementioned
   metrics in [RFC3550].

   Consequently, [RFC5725] specifies a post-repair loss Run-Length
   Encoding (RLE) XR report block to address this issue.  The sending
   endpoint is able to infer which packets were repaired from the RLE
   report block, but the reporting overhead for the packet-by-packet
   report block is higher compared to other report blocks.
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   When applications use multiple XR blocks, the endpoints may require
   more concise reporting to save bandwidth.  This document defines a
   new XR block type to augment those defined in [RFC3611] and
   complement the report block defined in [RFC5725] for use in a range
   of RTP applications.  This new block type reports the post-repair
   loss count metric, which records the number of primary source RTP
   packets that are still lost after applying one or more loss-repair
   mechanisms.  In addition, another metric, repaired loss count, is
   also introduced in this report block for calculating the pre-repair
   loss count during this range, so that the RTP sender or a third-party
   entity is able to evaluate the effectiveness of the repair methods
   used by the system.  The metrics defined in this document are packet
   level rather than slice/picture level; this means the partial
   recovery of a packet will not be regarded as a repaired packet.

   The metrics defined in this document belong to the class of
   transport-related metrics defined in [RFC6792] and are specified in
   accordance with the guidelines in [RFC6390] and [RFC6792].  These
   metrics are applicable to any RTP application, especially those that
   use loss-repair mechanisms.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

   primary source RTP packet: The original RTP packet sent from the RTP
      sender for the first time.  A lost primary source RTP packet may
      be repaired by some other RTP packets used in repair mechanisms
      like FEC or retransmission.

3.  Post-Repair Loss Count Metrics Report Block

   This block reports the number of packets lost after applying repair
   mechanisms (e.g., FEC).  It complements the RTCP XR metrics defined
   in [RFC5725].  As noted in [RFC5725], ambiguity may occur when
   comparing this metric with a pre-repair loss metric reported in an
   RTCP SR/RR, i.e., some packets were not repaired in the current RTCP
   interval, but they may be repaired later.  Therefore, this block uses
   a begin sequence number and an end sequence number to explicitly
   indicate the actual sequence number range reported by this RTCP XR.
   Accordingly, only packets that have no further chance of being
   repaired and that have been repaired are included in this report
   block.
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3.1.  Report Block Structure

   The Post-Repair Loss Count Metrics Report Block has the following
   format:

      0               1               2               3               4
      0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     BT=33     |   Reserved    |      Block length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       SSRC of Source                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       begin_seq               |          end_seq              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Post-repair loss count       |     Repaired loss count       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Block Type (BT): 8 bits

      A Post-Repair Loss Count Metrics Report Block is identified by the
      constant 33.

   Reserved: 8 bits

      These bits are reserved for future use.  They MUST be set to zero
      by senders and ignored by receivers (see Section 4.2 of
      [RFC6709]).

   Block length: 16 bits

      This field is in accordance with the definition in [RFC3611].  In
      this report block, it MUST be set to 4.  The block MUST be
      discarded if the block length is set to a different value.

   SSRC of source: 32 bits

      As defined in Section 4.1 of [RFC3611].

   begin_seq: 16 bits

      The first sequence number that this block reports on.  It can
      remain fixed when calculating metrics over several RTCP reporting
      intervals.

   end_seq: 16 bits

      The last sequence number that this block reports on plus one.




Singh & Huang                Standards Track                    [Page 4]

RFC 7509             Post-Repair Non-RLE Loss Count             May 2015


   Post-repair loss count: 16 bits

      Total number of packets finally lost after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      This metric MUST NOT count the lost packets for which repair might
      still be possible.  Note that this metric MUST measure only
      primary source RTP packets.

   Repaired loss count: 16 bits

      Total number of packets fully repaired after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      Note that this metric MUST measure only primary source RTP
      packets.

3.2  Example Usage

   The metrics defined in this report block are all measured at the RTP
   receiver.  However, the receiving endpoint can report the metrics in
   two different ways:

   1) Cumulative report

   In this case, implementations may set begin_seq to the first packet
   in the RTP session, and it will remain fixed across all reports.
   Hence, the "Post-repair loss count" and "Repaired loss count",
   respectively, will correspond to "Cumulative post-repair loss count"
   and "Cumulative repaired loss count" in this case.  These cumulative
   metrics when combined with the cumulative loss metrics reported in an
   RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired
   lost packets":

      Still-to-be-repaired lost packets =
            Cumulative number of packets lost -
            Cumulative post-repair loss count -
            Cumulative repaired loss count

   2) Interval report

   Some implementations may align the begin_seq and end_seq number with
   the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
   This is NOT RECOMMENDED as packets that are not yet repaired in this
   current RTCP interval and may be repaired in the subsequent intervals
   will not be reported.  An interval report is illustrated in the
   following example:




Singh & Huang                Standards Track                    [Page 5]

RFC 7509             Post-Repair Non-RLE Loss Count             May 2015


      Interval A: The extended highest sequence number received in RTCP
                  RR is 20.  Begin_seq is 10 and end_seq is 20.

      Interval B: The extended highest sequence number received in RTCP
                  RR is 30.  Begin_seq is 20 and end_seq is 30.

   If packets 17 and 19 are lost and not yet repaired in interval A and
   subsequently repaired in interval B, they will not be reported
   because their sequence numbers do not belong in interval B.
   Therefore, if implementations want these packets to be reported as
   repaired, they MUST NOT align the begin_seq and end_seq to the RTCP
   intervals.

   Alternatively, implementations may choose the begin_seq and end_seq
   numbers that cover several RTCP intervals.  Additionally, the
   reported range of sequence numbers may overlap with the previous
   report blocks, so that the packets that were not yet repaired in one
   interval, but were subsequently repaired or deemed unrepairable, were
   reported in subsequent intervals.

   In this case, the "Cumulative number of packets lost" cannot be
   easily compared with the post-repair metrics.  However, the sending
   endpoint can calculate the efficiency of the error resilience
   algorithm using the post-repair and repaired loss count,
   respectively.

4.  SDP Signaling

   [RFC3611] defines the use of SDP (Session Description Protocol) for
   signaling the use of RTCP XR blocks.  However, XR blocks MAY be used
   without prior signaling (see Section 5 of [RFC3611]).

4.1.  SDP rtcp-xr-attrib Attribute Extension

   This session augments the SDP attribute "rtcp-xr" defined in Section
   5.1 of [RFC3611] by providing an additional value of "xr-format" to
   signal the use of the report block defined in this document.  The
   ABNF [RFC5234] syntax is as follows.

   xr-format =/ xr-prlr-block

   xr-prlr-block = "post-repair-loss-count"









Singh & Huang                Standards Track                    [Page 6]

RFC 7509             Post-Repair Non-RLE Loss Count             May 2015


4.2.  Offer/Answer Usage

   When SDP is used in offer/answer context, the SDP Offer/Answer usage
   defined in [RFC3611] for the unilateral "rtcp-xr" attribute
   parameters applies.  For detailed usage of Offer/Answer for
   unilateral parameters, refer to Section 5.2 of [RFC3611].

5.  Security Considerations

   This proposed RTCP XR block introduces no new security considerations
   beyond those described in [RFC3611].  This block does not provide
   per-packet statistics, so the risk to confidentiality documented in
   Section 7, paragraph 3 of [RFC3611] does not apply.

   An attacker may put incorrect information in the Post-Repair Loss
   Count reports, which will affect the performance of loss-repair
   mechanisms.  Implementers should consider the guidance in [RFC7202]
   for using appropriate security mechanisms, i.e., where security is a
   concern, the implementation should apply encryption and
   authentication to the report block.  For example, this can be
   achieved by using the AVPF profile together with the Secure RTP
   profile as defined in [RFC3711]; an appropriate combination of the
   two profiles (an "SAVPF") is specified in [RFC5124].  However, other
   mechanisms also exist (documented in [RFC7201]) and might be more
   suitable.

6.  IANA Considerations

   New block types for RTCP XR are subject to IANA registration.  For
   general guidelines on IANA considerations for RTCP XR, refer to
   [RFC3611].

6.1.  New RTCP XR Block Type Value

   This document assigns the block type value 33 in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Post-Repair Loss Count Metrics Report Block".

6.2.  New RTCP XR SDP Parameter

   This document also registers a new parameter "post-repair-loss-count"
   in the "RTP Control Protocol Extended Reports (RTCP XR) Session
   Description Protocol (SDP) Parameters Registry".

6.3.  Contact Information for Registrations

   The contact information for the registrations is:
      RAI Area Directors <rai-ads@ietf.org>
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Appendix A.  Metrics Represented Using the Template from RFC 6390

   a.  Post-Repair RTP Packet Loss Count Metric

       *  Metric Name: Post-Repair RTP Packet Loss Count Metric.

       *  Metric Description: Total number of RTP packets still lost
          after loss-repair methods are applied.

       *  Method of Measurement or Calculation: See the "Post-repair
          loss count" definition in Section 3.1.  It is directly
          measured and must be measured for the primary source RTP
          packets with no further chance of repair.

       *  Units of Measurement: This metric is expressed as a 16-bit
          unsigned integer value giving the number of RTP packets.

       *  Measurement Point(s) with Potential Measurement Domain: It is
          measured at the receiving end of the RTP stream.

       *  Measurement Timing: This metric relies on the sequence number
          interval to determine measurement timing.  See the Cumulative
          and Interval reports defined in Section 3.2.

       *  Use and Applications: These metrics are applicable to any RTP
          application, especially those that use loss-repair mechanisms.
          See Section 1 for details.

       *  Reporting Model: See RFC 3611.

   b. Repaired RTP Packet Loss Count Metric

       *  Metric Name: Repaired RTP Packet Count Metric.

       *  Metric Description: The number of RTP packets lost but
          repaired after applying loss-repair methods.

       *  Method of Measurement or Calculation: See the "Repaired loss
          count" in Section 3.1.  It is directly measured and must be
          measured for the primary source RTP packets with no further
          chance of repair.

       *  Units of Measurement: This metric is expressed as a 16-bit
          unsigned integer value giving the number of RTP packets.

       *  Measurement Point(s) with Potential Measurement Domain: It is
          measured at the receiving end of the RTP stream.
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       *  Measurement Timing: This metric relies on the sequence number
          interval to determine measurement timing.  See the Cumulative
          and Interval reports defined in Section 3.2.

       *  Use and Applications: These metrics are applicable to any RTP
          application, especially those that use loss-repair mechanisms.
          See Section 1 for details.

       *  Reporting Model: See RFC 3611.
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